Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix 'zfs change-key' with unencrypted child #9524

Merged
merged 1 commit into from
Oct 30, 2019

Conversation

tcaputi
Copy link
Contributor

@tcaputi tcaputi commented Oct 28, 2019

Currently, when you call 'zfs change-key' on an encrypted dataset
that has an unencrypted child, the code will trigger a VERIFY.
This VERIFY is leftover from before we allowed unencrypted
datasets to exist underneath encrypted ones. This patch fixes the
issue by simply replacing the VERIFY with an early return when
recursing through datasets.

Signed-off-by: Tom Caputi tcaputi@datto.com

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Performance enhancement (non-breaking change which improves efficiency)
  • Code cleanup (non-breaking change which makes code smaller or more readable)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation (a change to man pages or other documentation)

Checklist:

@@ -1452,7 +1452,11 @@ spa_keystore_change_key_sync_impl(uint64_t rddobj, uint64_t ddobj,
* Stop recursing if this dsl dir didn't inherit from the root
* or if this dd is a clone.
*/
VERIFY0(dsl_dir_get_encryption_root_ddobj(dd, &curr_rddobj));
if (dsl_dir_get_encryption_root_ddobj(dd, &curr_rddobj) == ENOENT) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens if this returns something other than 0 or ENOENT?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I should probably add a VERIFY0() after the check. We shouldn't be able to hit any other error case in syncing context, in theory. In reality, we can probably hit an IO error here which isn't checked in the check function. I'm not sure if it would be a good idea to do that check though, because that function might have to recurse through an arbitrary number of datasets. For now. I will just add a VERIFY0()

@behlendorf behlendorf added the Status: Code Review Needed Ready for review and testing label Oct 28, 2019
@tcaputi tcaputi force-pushed the fix_change_key_unencrypted branch from 2702f39 to 543f9bc Compare October 28, 2019 19:54
VERIFY0(dsl_dir_get_encryption_root_ddobj(dd, &curr_rddobj));
if (!skip && (curr_rddobj != rddobj || dsl_dir_is_clone(dd))) {

ret = dsl_dir_get_encryption_root_ddobj(dd, &curr_rddobj);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know if it's a huge concern, but it looks like there's a chance a non-zero or non-ENOENT return could get past the VERIFY check by triggering the return path here (I realized that with my own attempt at this after my initial fix).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good catch. fixed.

@codecov
Copy link

codecov bot commented Oct 29, 2019

Codecov Report

Merging #9524 into master will decrease coverage by 0.16%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #9524      +/-   ##
==========================================
- Coverage   79.16%      79%   -0.17%     
==========================================
  Files         416      416              
  Lines      123661   123663       +2     
==========================================
- Hits        97895    97697     -198     
- Misses      25766    25966     +200
Flag Coverage Δ
#kernel 79.69% <100%> (-0.06%) ⬇️
#user 66.47% <0%> (-0.47%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d46f0de...997916d. Read the comment docs.

Copy link
Contributor

@ikozhukhov ikozhukhov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently, when you call 'zfs change-key' on an encrypted dataset
that has an unencrypted child, the code will trigger a VERIFY.
This VERIFY is leftover from before we allowed unencrypted
datasets to exist underneath encrypted ones. This patch fixes the
issue by simply replacing the VERIFY with an early return when
recursing through datasets.

Signed-off-by: Tom Caputi <tcaputi@datto.com>
@tcaputi tcaputi force-pushed the fix_change_key_unencrypted branch from 543f9bc to 997916d Compare October 29, 2019 15:36
@behlendorf behlendorf added Status: Accepted Ready to integrate (reviewed, tested) and removed Status: Code Review Needed Ready for review and testing labels Oct 29, 2019
Copy link
Contributor

@ikozhukhov ikozhukhov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tested on dilos, no issues found

@behlendorf behlendorf merged commit bae11ba into openzfs:master Oct 30, 2019
cvoltz pushed a commit to cvoltz/zfs that referenced this pull request Nov 1, 2019
Currently, when you call 'zfs change-key' on an encrypted dataset
that has an unencrypted child, the code will trigger a VERIFY.
This VERIFY is leftover from before we allowed unencrypted
datasets to exist underneath encrypted ones. This patch fixes the
issue by simply replacing the VERIFY with an early return when
recursing through datasets.

Reviewed by: Jason King <jason.brian.king@gmail.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Igor Kozhukhov <igor@dilos.org>
Signed-off-by: Tom Caputi <tcaputi@datto.com>
Closes openzfs#9524
tonyhutter pushed a commit to tonyhutter/zfs that referenced this pull request Dec 26, 2019
Currently, when you call 'zfs change-key' on an encrypted dataset
that has an unencrypted child, the code will trigger a VERIFY.
This VERIFY is leftover from before we allowed unencrypted
datasets to exist underneath encrypted ones. This patch fixes the
issue by simply replacing the VERIFY with an early return when
recursing through datasets.

Reviewed by: Jason King <jason.brian.king@gmail.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Igor Kozhukhov <igor@dilos.org>
Signed-off-by: Tom Caputi <tcaputi@datto.com>
Closes openzfs#9524
tonyhutter pushed a commit to tonyhutter/zfs that referenced this pull request Dec 27, 2019
Currently, when you call 'zfs change-key' on an encrypted dataset
that has an unencrypted child, the code will trigger a VERIFY.
This VERIFY is leftover from before we allowed unencrypted
datasets to exist underneath encrypted ones. This patch fixes the
issue by simply replacing the VERIFY with an early return when
recursing through datasets.

Reviewed by: Jason King <jason.brian.king@gmail.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Igor Kozhukhov <igor@dilos.org>
Signed-off-by: Tom Caputi <tcaputi@datto.com>
Closes openzfs#9524
tonyhutter pushed a commit that referenced this pull request Jan 23, 2020
Currently, when you call 'zfs change-key' on an encrypted dataset
that has an unencrypted child, the code will trigger a VERIFY.
This VERIFY is leftover from before we allowed unencrypted
datasets to exist underneath encrypted ones. This patch fixes the
issue by simply replacing the VERIFY with an early return when
recursing through datasets.

Reviewed by: Jason King <jason.brian.king@gmail.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Igor Kozhukhov <igor@dilos.org>
Signed-off-by: Tom Caputi <tcaputi@datto.com>
Closes #9524
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Accepted Ready to integrate (reviewed, tested)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants